跳到主要内容

Agentic Engineering（原 Vibe Engineering）

Simon Willison 在 2025-10-07 提出 Vibe Engineering，作为 Vibe Coding（凭感觉、不为结果负责）的对立面。2026-02-23 他更新文章承认社区已经统一用 Agentic Engineering 这个术语。本篇讲清楚这套范式：资深工程师如何用 AI 加速工作，同时为代码完全负责。

学前说明​

这是一个关于身份和工作方式的章节，不是技术教程。

2025 年下半年，软件工程师群体出现了清晰的两极分化：

一端是 Vibe Coding——快速、随性、不负责。Andrej Karpathy 在 2025 年 2 月发明这个词，指的是"完全靠 prompt 驱动、不关心代码怎么工作"的开发方式。适合周末小项目、原型验证。但越来越多人把 Vibe Coding 当成主业，写出的代码自己也看不懂。

另一端就是 Agentic Engineering——经验丰富的工程师用 AI 工具大幅加速，但对产出的软件完全负责。这才是把 Coding Agent 真正用在生产环境的方式。

两者的分界线很简单：「我能不能自信地维护这段代码」。

为什么这一章重要​

5-8 和 05 讲了"怎么用 Coding Agent"。但这一章回答更根本的问题：

  • 用 AI 之后，工程师的核心技能变成了什么？
  • 哪些传统好习惯在 AI 时代价值翻倍？
  • 哪些新技能是 AI 时代独有的？
  • 怎么判断一个团队/个人是 Vibe Coding 还是 Agentic Engineering？

学习目标​

  • 理解 Vibe Coding 和 Agentic Engineering 的本质区别
  • 掌握 12 项 Agentic Engineering 核心实践
  • 评估自己/团队在两个极端中的位置
  • 建立向 Agentic Engineering 迁移的路径
  • 重新校准对工时估算的判断

与现有知识的衔接​

  • 5-8 Coding Agent：工具使用（前置）
  • 05 Parallel & Async Coding Agents：并行工作流（前置）
  • 04 Lethal Trifecta：YOLO 模式的安全边界
  • 02 Skills 体系：Skills 是 Agentic Engineering 的高级工具

第一章：Vibe Coding vs Agentic Engineering​

1.1 定义​

Vibe Coding（Karpathy, 2025-02）

一种用 AI 编程的新方式：完全凭直觉。我描述我想要什么，AI 写代码，我看一眼觉得对就接受。我不真正理解代码。

特点：

  • 完全 prompt 驱动
  • 不关心实现细节
  • 不为代码维护负责
  • 出问题靠继续 prompt 修
  • 适合一次性、低风险任务

Agentic Engineering（Simon Willison, 2025-10）

经验丰富的专业工程师用 LLM 加速工作，同时自豪且自信地为他们产出的软件负责。

特点：

  • AI 大幅提速
  • 工程师完全理解所有产出的代码
  • 对长期维护负责
  • 强烈的代码 review 文化
  • 适合生产代码、长期项目

1.2 两者不是等级关系，是适用场景​

很多人误以为 Agentic Engineering 是 Vibe Coding 的"高级版"。错。它们解决不同问题：

场景合适方式理由
周末玩具项目Vibe Coding出问题没关系，乐趣大于风险
一次性脚本（数据清洗）Vibe Coding用完即弃
客户原型 demoVibe Coding验证想法，不上生产
公司核心业务代码Agentic Engineering必须长期维护
开源项目维护Agentic Engineering别人也要看懂
团队协作代码Agentic Engineering同事要 review
涉及金钱/隐私Agentic Engineering出错代价大

关键判断：问自己一句话——「这段代码 3 个月后我或我的同事还要维护吗？」是 → Agentic Engineering。否 → Vibe Coding 也行。

1.3 中间地带最危险​

实际上，最大的问题不是"该用哪种"，而是很多人用 Vibe Coding 的方式做了应该用 Agentic Engineering 的事。

典型表现：

  • 用 prompt 写了 production 代码，没读懂就 commit
  • bug 来了继续 prompt 让 AI 修，越改越复杂
  • 半年后离职/接手的人完全看不懂
  • 没有测试，但 AI 一直说"看起来能跑"
  • 没有文档，靠"再 prompt 一遍 AI 就知道"

这是 2026 年最大的技术债来源。

第二章：Agentic Engineering 的 12 项核心实践​

来自 Simon Willison 原文，每一条都解释了"为什么 AI 让这件事更重要"。

2.1 自动化测试（Automated Testing）​

如果你的项目有一套完整、稳定的测试，agent 能飞起来。没有测试？Agent 可能声称代码"能工作"，但实际根本没测过。

为什么 AI 时代价值翻倍：

  • Coding Agent 在 loop 里跑测试 → 测试是 Agent 的"事实判定标准"
  • AI 写代码快 → 改动多 → 回归 bug 风险大 → 必须有自动测试兜底
  • Test-first development 跟 agent 配合特别好

实战：

# 给 Agent 的标准指令模板
> 实现功能 X。完成后必须满足：
> 1. pnpm test 全部通过
> 2. 新代码覆盖率 > 80%（pnpm test:coverage）
> 3. 不能修改测试文件来让测试通过

最后一条很关键——Agent 经常为了"测试通过"去改测试。明确禁止。

2.2 提前规划（Planning in Advance）​

跟 agent 工作让规划更重要——你可以先在规划上迭代，再让 agent 写代码。

为什么 AI 时代价值翻倍：

  • 没规划就 prompt：Agent 自己想方案，可能完全偏离你的架构
  • 有规划：Agent 按你的方向走，review 时只看"是否符合规划"

参考 05 第六章的 Architect → Implementor 模式。

2.3 全面的文档（Comprehensive Documentation）​

跟人类程序员一样，LLM 一次只能把 codebase 的一部分放进 context。好的文档让它能用你 codebase 其他部分的 API 而不用读源码。

为什么 AI 时代价值翻倍：

  • AI 不能一次读完 100 万行代码
  • 文档是"高密度的 context 喂料"
  • 写好 API 文档后，AI 能基于文档直接写实现

实战：在你的 CLAUDE.md、README.md、docs/ 里维护：

  • 每个模块的职责（一段话）
  • 关键 API 的签名和示例
  • 项目约定（命名、错误处理、状态管理）
  • 已知的坑和解决方案

2.4 好的版本控制习惯（Good Version Control Habits）​

在 Agent 可能改了任何代码的世界里，能撤销错误、能查清楚谁什么时候改了什么——比以前更重要。LLM 在 Git 上非常厉害——它们可以追溯历史、找 bug 起源，用 git bisect 比大多数开发者还好。

为什么 AI 时代价值翻倍：

  • AI 改完不一定对，必须能快速回滚
  • 频繁 commit 让"哪一步出问题"清晰可查
  • git bisect 用 AI 跑特别快

实战习惯：

# AI 干活前先 commit
git add . && git commit -m "wip: 准备让 agent 改 X"

# AI 干完
git diff  # 看改动
pnpm test  # 验证
git add . && git commit -m "feat: implement X (agent-assisted)"

# 不对？一键回滚
git reset --hard HEAD^

2.5 有效的自动化（Effective Automation）​

持续集成、自动格式化、自动 lint、自动 deploy preview——这些都让 agent 受益。LLM 也让写自动化脚本更容易。

为什么 AI 时代价值翻倍：

  • Agent 跑了写好的脚本 = 你不用一步步指导
  • CI/CD 给 Agent 持续反馈
  • AI 帮你写新的自动化脚本（飞轮）

2.6 代码审查文化（Culture of Code Review）​

这条不用解释。如果你审查代码又快又好，跟 LLM 工作就如鱼得水。如果你宁可自己写也不愿审别人写的，那跟 AI 一起工作会很痛苦。

为什么 AI 时代价值翻倍：

  • AI 写代码远快于人审查 → review 成了瓶颈
  • 不擅长 review 的人无法用好 AI
  • review 技能 = AI 时代的核心竞争力

校验自己：

  • 你能 10 分钟看完一份 200 行的 PR 并发现关键问题吗？
  • 你看 diff 时能脑补"这改动会影响哪些地方"吗？
  • 你能在 PR 评论里写出"建议 + 理由 + 替代方案"吗？

不行 → 你的 AI 利用率不会高。

2.7 奇怪的"管理"技能（A Very Weird Form of Management）​

从 Coding Agent 拿到好结果，跟从人类协作者拿到好结果很像。你需要给清晰指令、确保有必要的 context、对产出给出可执行的反馈。

为什么 AI 时代价值翻倍：

  • 给 AI 指令的能力 = 给初级工程师指令的能力
  • 不善管理的人 = 不善"管理 AI"
  • 反过来，管理经验在 AI 时代有意外用武之地

但有个 Simon 提到的有趣点：

管理 AI 比管理人简单，因为你不用担心冒犯或打击对方。

意思是你可以更直接：「这个实现不对，重写」「为什么没考虑 X 边界」——对 AI 说这些没心理负担。

2.8 强大的手工 QA（Really Good Manual QA）​

除了自动化测试，你需要非常擅长手动测试软件，包括预测和深挖边界情况。

为什么 AI 时代价值翻倍：

  • AI 写的代码"看起来对"是常态，但边界 case 经常漏
  • 自动化测试覆盖不到的，必须人来测
  • 老练工程师的"直觉测试点"——AI 时代依然不可替代

实战：每个 AI 实现的功能，至少手动测：

  • 空输入 / 极大输入 / 极小输入
  • 网络断 / 后端慢 / 后端 500
  • 并发场景（多人同时操作）
  • 浏览器后退、刷新、关闭 tab
  • 国际化（中文、emoji、阿拉伯语）

2.9 强大的研究能力（Strong Research Skills）​

一个编程问题有几十种解法。找出最优方案、证明可行——这件事一直很重要，现在依然是 unleash agent 写代码前的瓶颈。

为什么 AI 时代价值翻倍：

  • AI 能写代码，但不能替你做技术选型
  • 选错方案，AI 高速实现一堆错的
  • 研究能力 = 决定 AI 给你 10x 还是 -3x

实战工具：

  • 用 ChatGPT/Perplexity 做技术调研，但自己验证关键决策
  • 派 Agent 做 PoC（参考 05 第二章模式 A）
  • 读官方文档原文，不只看 AI 总结

2.10 部署到 Preview 环境（Ship to Preview Environment）​

如果 Agent 构建了一个功能，安全地预览它（不直接 deploy 生产）让 review 更高效，也大幅降低上错代码的风险。

为什么 AI 时代价值翻倍：

  • AI 写得快 → 上 staging 频率高
  • 没 preview → 要么本地试（慢）要么直上生产（险）
  • 现代 Vercel/Netlify 自动 preview = 完美匹配

实战：每个 PR 自动起 preview，AI 改完你点开链接就能看效果。

2.11 判断"什么能外包给 AI"的直觉​

这是持续演进的——模型和工具越来越强。跟 LLM 高效工作的很大一部分，是保持对"什么时候用 AI 最有效"的强烈直觉。

为什么 AI 时代价值翻倍：

  • 半年前不能给 AI 的事，今天可能能
  • 半年前 AI 做不好的事，今天可能做得好
  • 不更新直觉 → 你的 AI 利用率落后于工具

实战：每月花 1-2 小时主动测试 AI 在新场景的能力。

2.12 更新工时估算（Updated Sense of Estimation）​

AI 让估算更难。过去要花很久的事现在快得多——但估算现在依赖新因素，我们都在搞清楚。

为什么 AI 时代价值翻倍：

  • "这功能要 2 周" → AI 时代可能 2 天 也可能 1 个月
  • 老的估算公式全部失效
  • 给老板汇报项目时这是高频痛点

Simon 提到这是高级工程师最难也最重要的技能之一。

第三章：核心洞察——AI 放大已有专业能力​

Simon 在文章里反复强调一句话：

AI tools amplify existing expertise.

你的软件工程技能和经验越多，跟 LLM 和 coding agent 一起工作的产出就越快、越好。

3.1 这意味着什么​

工程师等级AI 加成实际产出
初级（1-2 年）1.2-1.5x略快，但常犯错
中级（3-5 年）2-3x显著快，质量稳定
高级（5+ 年）5-10x飞跃式提升
专家（10+ 年）10x+重新定义"一个人能做什么"

为什么？因为：

  • 高级工程师知道要做什么（AI 不会问）
  • 高级工程师能 review 别人代码（AI 写的也能 review）
  • 高级工程师有架构 sense（AI 不会自动避坑）
  • 高级工程师懂工程实践（自动化测试、CI/CD）

3.2 反过来的推论​

新手用 AI 不会变成专家。一些声音说"AI 让初级工程师快速变高级"——错。AI 让初级工程师产出看起来像中级，但他们的判断力和系统理解还是初级。

这就是中间地带的危险：看起来能交付，遇到复杂问题崩溃。

3.3 给个人和团队的启示​

给个人：

  • 不要因为 AI 强就放弃练基本功
  • 学软件工程比学怎么用 AI 更重要
  • 上面 12 条没掌握的，先补这些

给团队：

  • 不要用 AI 取代培训新人，反而要加强培训
  • 招人时考察review 能力 + 工程素养，不只是写代码
  • 给团队建立 12 条对应的基础设施

第四章：评估自己的位置​

4.1 自评矩阵​

对以下 12 项打分（1-5）：

#实践自评（1-5）
1自动化测试__
2提前规划__
3全面文档__
4版本控制__
5自动化__
6代码审查__
7管理（AI）能力__
8手工 QA__
9研究能力__
10Preview 部署__
11AI 适用场景直觉__
12工时估算__

总分判断：

总分你的位置建议
12-24Vibe Coder用 AI 玩玩，别上生产
25-36中间地带（危险）立即补短板，否则代码会爆
37-48早期 Agentic Engineer继续打磨，找 1-2 项重点突破
49-60成熟 Agentic Engineer教别人吧

4.2 常见短板模式​

模式 A：会写但不会审

  • 高项：1, 3, 9
  • 低项：6, 8
  • 病根：习惯自己写，AI 写的看着烦
  • 处方：练 review，先从小 PR 开始

模式 B：会审但不会规划

  • 高项：6, 9
  • 低项：2, 12
  • 病根：习惯被动响应需求
  • 处方：每个任务前强制写 5 分钟"规划"

模式 C：技术好但工程差

  • 高项：1, 9
  • 低项：3, 5, 10
  • 病根：单兵作战出身，没经历过团队基础设施建设
  • 处方：花 1-2 周专门补工程基础设施

4.3 团队评估​

把 12 项对全员算平均分。再看：

  • 哪一项团队平均低于 3？这是团队级短板，要建机制
  • 哪几个人在某项显著低？这些人是培训重点

第五章：从 Vibe Coding 迁移到 Agentic Engineering​

如果你或团队还在中间地带，下面是务实的迁移路径。

5.1 90 天迁移计划​

第 1 月：建基础

  • 给主力项目加上完整测试（覆盖率 > 60%）
  • 建 CI（lint + test + build 必过）
  • 写一份 CLAUDE.md / 项目规范

第 2 月：换工作流

  • 强制要求"AI 写代码必须先 commit"
  • 强制要求"AI 写完跑测试再 commit"
  • 强制要求"AI 写的 PR 必须 review"
  • 引入 preview 部署

第 3 月：升级技能

  • 每周 1 次"AI 用法分享"，团队互学
  • 引入并行 Agent 工作流（参考 05）
  • 建立工时估算的新基线

5.2 不要做的事​

  • ❌ 一上来就追求"all in AI"——容易失控
  • ❌ 因为短期慢就放弃测试——你在埋雷
  • ❌ 把所有 review 都给 AI 做——人的判断不能省
  • ❌ 引入太多并行 Agent——超过自己 review 能力就是负担
  • ❌ 跳过 PR 直接 push main——你给自己埋的最大的雷

5.3 团队的文化建设​

Agentic Engineering 不只是工具问题，更是文化问题：

文化Vibe TeamAgentic Team
对 AI 代码的态度"AI 写的我没看""AI 写的也是我的代码"
Bug 归属"AI 写错了""我没 review 出来"
学习方式"我让 AI 解释""AI 解释 + 我读官方文档"
招聘"会用 AI 就行""工程基础 + 会用 AI"
代码 review"能跑就 LGTM""理解每一行才 LGTM"

第六章：常见反问​

问：Vibe Coding 完全不能用吗？

不是。一次性脚本、玩具项目、PoC、个人小工具——Vibe Coding 完全 OK。关键是你知道你在 Vibe Coding，而且场景合适。

问：我做的就是 Vibe Coding 风格的工具/创意类项目，需要变成 Agentic Engineering 吗？

如果只有你一个人维护、出错没关系、不长期演进——继续 Vibe Coding 没问题。 如果你的"小工具"变成了用户依赖的产品、出错有代价、需要长期维护——必须升级。

问：Agentic Engineering 会被新 AI 替代吗？

短期不会。AI 越强，对"管 AI 的人"的判断力要求越高。Simon 原话：

你不只是写代码——你在研究方案、决定架构、写规范、定义验收标准、设计 agentic loop、规划 QA、管理一支越来越大的怪异数字实习生大军（他们如果有机会一定会作弊）、花大量时间在 code review 上。

这些是高级工程师的核心能力，AI 加强而不是替代。

问：怎么判断一个候选人/同事是 Vibe Coder 还是 Agentic Engineer？

最快的方法：让他口头解释他最近一周 AI 帮他写的某段代码。

  • Vibe Coder：解释不清，"反正能跑"
  • Agentic Engineer：能讲清楚每个决策、替代方案、为什么 AI 这么写

问：12 项里最优先补哪个？

如果只能选一个：自动化测试（#1）。

理由：

  • 它是其他所有实践的基础
  • 没有测试，你和 AI 都在黑盒操作
  • 有测试，AI 才能真正进入 loop 模式

第二优先：代码审查（#6）。 第三优先：版本控制（#4）。

第七章：未来方向​

7.1 Agentic Engineering 工具化​

2026 年开始出现专门的 "agentic engineering 平台"：

  • 自动测试生成 + 维护
  • 自动文档生成 + 同步
  • 团队级 Agent 配置共享
  • 工时估算辅助（基于历史 AI 任务数据）

7.2 角色分化​

可能演化出新的工程角色：

  • Agent Wrangler：专门管理一群 Agent 的工程师
  • Spec Writer：写高质量 Agent 规范的人
  • AI Code Reviewer：专门 review AI 代码的（暂时人做，未来 AI 做）

7.3 教育和招聘​

  • 计算机教育会从"写代码"转向"工程实践"
  • 招聘考察从"算法题"转向"review + 架构"
  • "用 AI 但说不清原理"会成为减分项

权威资料​

核对日期：2026-06-12